The above findings can be summarized briefly as follows:

Microsoft StreamInsight has strict requirements on time monotony, which OPC cannot fulfill directly.

While the above statement may sound somewhat pessimistic, there are several ways how to adapt OPC times to StreamInsight, and we will mention some of them here. There is also material available from Microsoft and on the Web from various sources that deals with such issues, because other data sources that are used to feed events into StreamInsight deal with the same or similar issues.

Here are some options that can be used in various situations, either alone, or in combination:

• Use current system time on the client side for StreamInsight time, i.e. do not use OPC timestamps at all. This is the approach used the in the simple examples shipped with the product, and in this document. The OPC timestamps become fields of the event payload, and can therefore have any valid value.
• You may use only single notification rate, or avoid combination of events from different sources before you advance the StreamInsight time.
• Use various AdvanceTimeSettings available in StreamInsight. For example, you may place an upper bound for how far back from the previous CTI the start time of the future event can be.  Using AdvanceTimePolicy, you can also choose whether incoming events with start time before the current application time are dropped, or simply adjusted to the current application time.

The way that you resolve the issue of adapting OPC times to StreamInsight depends completely on the needs of your application, and there is no single approach that fits all applications.